Office equipment, such as printers or copiers, typically uses a software-based operating system to perform essential machine functions and implement the various jobs of which the machine is capable. However, software, particularly that used in high-speed multi-function machines, is subject to various problems and faults. Additional problems also arise with the machine hardware which, in machines of this type, is extremely complex and sophisticated. Hardware and software problems that occur typically happen at a low, non-periodic rate and thus are very difficult to replicate when servicing the machine and therefore difficult to resolve. Further, many of these problems are identified by the customer, who is typically not technically trained to diagnose and service machines of this type. For this reason, it is important for a servicing organization to be able to access key machine operating information, and particularly information reflecting on the performance of the machine control system and physical states of machine componentry.
A common feature of the business arrangement between the user of the equipment and the supplier is that the user is responsible, at least in part, for some maintenance and basic trouble-shooting of the equipment. Often the equipment has componentry that can be tested, manipulated and perhaps replaced by the user, but in view of the investment in the equipment, users are reluctant to engage in system repair without the strong support of the supplier and its service departments. Accordingly, enhancing the accuracy and efficiency of equipment service is based on particularly articulating or determining equipment status and the occurring problem to a remote trouble-shooting service department. Frustrating experiences with the telephone communication-to-tech support departments is universally known and the problems with unsophisticated customers trying to actually communicate a problem to the department are extremely common.
Typically, when a user encounters a problem with a machine and cannot resolve it (or does not want to solve it himself, he (or a user representative) calls a support organization for assistance, such organizations typically have troubleshooters available to help. After salient details such as the machine serial number have been taken, the troubleshooter tries to ascertain the character and extent of the problem. When the nature of the problem and its possible causes have been uncovered, the troubleshooter will either propose some ways to attempt to resolve the problem or decide at this point that the call is best passed to higher level support. Where the troubleshooter attempts to get the user to resolve the problem, aside from his own knowledge and experience he may make use of a range of resources, such as an online knowledge base, physical machines, or the advice of colleagues.
The interactions between a user experiencing a problem with a machine and a troubleshooter on the phone recurrently involve a number of phenomena. The user and the troubleshooter between them build up a description of the problem that enables consideration of what an appropriate solution might be. This can include:                the provision by the user of an initial problem description, often containing a range of contextual information about the situation the problem has arisen in;        the reformulation of this description by the troubleshooter, into terms more specifically relevant to locating a solution;        affirmation/refinement of this description by the user;        potential further joint refinement of the problem/collation of other relevant features (either verbally or by getting the user to ‘go look’); and,        working together through instruction, implementation, and feedback to try out possible solutions.        
In doing this work both the user and the troubleshooter routinely describe physical elements of the machine and give spatial directions or descriptions. It is often necessary to describe machine parts because users do not necessarily have the technical vocabulary to identify machine parts by name. The situation in which this particular problem with this particular machine arose has to be made available, where either party may only have partial information. The full extent of the problem also needs to be inquired into and made available. This may involve asking the user to undertake additional testing activities and report back. Potential solutions must be located and instructions given, followed, and their outcomes provided.
These interactions also typically take place under circumstances where the interactants only have access to an audio channel (telephone) which is not necessarily (physically) located by the machine, thereby requiring the user to negotiate a means of accessing the machine while retaining contact with the troubleshooter. The audio channel alone means that all descriptions, instructions and feedback are only verbal and the user will be the sole source of the initial problem description, circumstantial information, the results of the attempted instructions, etc. This can result in the troubleshooter requesting that the user repeat actions, either because they do not know the user has already done these, or because they cannot be sure the user has done these correctly. For the troubleshooter, where possible solutions come from textual resources, they will have to be digested from text and then articulated through purely verbal means. As a consequence of these circumstances a number of issues arise where the resolution is, at best, sub-optimal:                The user may lack access to the machine while on the phone and need to devote effort to coordinating access with others or constantly moving between the phone and the machine.        Troubleshooters will lack potentially significant and relevant information about the current machine status, the previous actions undertaken by the user, and the machine's previous behavior.        There is a lack of mutual access to the machine resulting in effort being devoted to:                    describing the current state and answering questions in order to arrive at a mutually agreed expression of the problem;            producing instructions and directions and reporting back without being able to see how instructions and directions might be appropriately framed to the current circumstance (necessitating potentially redundant feedback and varying degrees of clarification); and            working out ways together to ensure that they are referring to the same physical components of the machine.                        
Out of these observations it is possible to recognize two inter-related and potentially critical barriers to fully effective troubleshooting via conventional means:                1. The site of the problem is removed form the site of resolution for user-machine interactions. Excessive physical movement and coordination may be demanded, there is an absence of potentially important information to relevant parties, and both the problem and the resolution must always be mediated by verbal means.        2. The user-troubleshooter interaction is not best facilitated solely over the phone. Restriction to verbal mediation only diminishes the capacity to recognize the current state of the machine, the user situation, the object of reference, and the import of instructions.        
The foregoing problems have suggested various needs for improved collaborative, distributed troubleshooting of network devices such as printers or MFDs (“multi-function devices”). There is a need for the improved communication of important information to be accomplished by the use of networking and user interface (“UI”) capabilities with the equipment to handle the collaboration between the user and troubleshooter, and to use sensors and actuators (LEDs in the equipment). More particularly, there is a need for the user-troubleshooter interaction to comprise making the equipment the infrastructural mediator between the troubleshooter and the user and to create a bi-directional Shared Visualization of the Problems (“SVP”) which the user and troubleshooter can manipulate to thereby make coordinated informed actions in order to troubleshoot the problem.
That is, the user should be able to access technical support through the machine and then carry out the interactions with the troubleshooter via an audio-visual communication channel. This enables both parties to have a real time understanding of the actions which are being or should be performed on the machine, providing a resource for overcoming the descriptive and spatial problems which currently affect troubleshooting. The visualization allows technical support to better utilize the abilities of the remote user to carry out actions on the machine.
A number of systems using video have been suggested or designed to support remote collaboration around locally situated objects. However, video can introduce interactional difficulties or may involve considerable overhead, requiring multiple cameras or sophisticated equipment.